Methods and systems of span design

ABSTRACT

Span design based on the organization of telecommunications components into a hierarchy of elements, segments, and/or architectures, the use of templates representing the hierarchy of components, and the conformity of the components to rules. In response to receipt of an order for digital services, the order data is used to obtain an assignment of components for the digital services. The order data and the assignment of components are used to obtain equipment data. The order data, the assignment of components and the equipment data are used to create the span design based on the templates.

FIELD OF THE INVENTIONS

The inventions relate to the field of telecommunications, andparticularly, to the field of span designs in provisioning digitaltelecommunications services to subscribers.

BACKGROUND

Various digital telecommunications services are available tosubscribers. Examples of such services include: Digital Signal Level 1(DS-1), Digital Signal Level 3 (DS-3), and/or Trunk Carrier Signal Level1 (T-1). To provide digital telecommunications service to a subscriber,additions or changes to the telecommunications network may have to bemade.

With respect to the parts of the telecommunications network that mayhave to be added to or changed to provide a subscriber with digitalservice, the part of the telephone network that connects the subscriberto an appropriate central office (C.O.) of the telecommunicationsnetwork is referred to as the “span” or “loop” for that particularsubscriber. In some cases, a subscriber's “span” may be that part of thenetwork directly between the subscriber's location and the nearest C.O.providing the desired digital service. In other cases, a subscriber's“span” may include a connection to a C.O., and then a further connectionfrom the connected C.O. to one or more other C.O.s so as to provide thesubscriber with the desired digital service.

When a subscriber subscribes to a digital service, a span design mayhave to be created so the appropriate elements, components, etc. areincluded in the span of the telecommunications network used to providethe digital service to the subscriber's location. Historically, spandesigns were created one-by-one and “manually” by a person reviewing therespective circumstances of each subscriber and adding or changingcomponents in the telecommunications network, and particularly in thespan, as appropriate. Additionally, a record of each span design isretained to aid in trouble shooting, trouble analysis and futurerearrangements of the network.

Manual creation of a span design required the person creating the spandesign to determine the appropriate components to be used for aparticular span. The determination of the appropriate components couldinvolve checking for the availability or suitability of components aswell as other checks. Some span designs contain a large number ofcomponents. Thus, it could take a person several hours, days, or evenweeks to complete a span design.

In some cases, a span designer could make use of a portion of or apre-existing span design in connection with a span design upon which heor she was working. Utilization of a pre-existing span design, in wholeor part, did not typically save time in design of another span design.Generally, this process did not save any time because the span designerhad to re-evaluate the pre-existing span design to insure its accuracy.Moreover, the span designer had to check for the continued availabilityor suitability of the components used in the pre-existing span design.As a result, manually providing each span design was a slow,inefficient, and cumbersome process.

Manually creating each span design, even though slow, inefficient, andcumbersome, was not considered a problem when few span designs werenecessary. Previously, digital telecommunications services such as DS-1,DS-3, and T-1 services were primarily utilized only by consumers havinghigh data volume or high telephone usage. For example, at first, onlytelemarketers, scientific companies, and similar entities utilized DS-1,DS-3, or T-1 lines. Thus, the pool of potential consumers was limited.Therefore, new span designs were required relatively infrequently.

Today, however, the pool of potential consumers for digital services ismuch larger thanks to the internet and other factors that have increasedconsumers' interest in and desire for digital services. Digital servicessuch as DS-1, DS-3, and T-1 services may be and are utilized by justabout anyone from internet service providers to family members.Consequently, many more span designs are needed to provide such servicesto consumers. Additionally, a majority of consumers expect services tobe provided shortly after ordering the services. Therefore, in today'stelecommunications market, the drawbacks of slowness, inefficiency andcumbersomeness associated with manually creating span designs are nolonger acceptable.

In an attempt to address these drawbacks, digital provisioning computerprograms were designed to mechanize the span design process. The digitalprovisioning programs included information about the availablecomponents and utilized the component information along with informationinput by a person to create a span design.

The digital provisioning programs, however, had their own drawbacks. Onedrawback was that the programs generally were inflexible because theycould not be easily updated to address changes in components orotherwise adjust to changed circumstances. For example, newarchitectures and components were being and continue to be designed andutilized for DS-1 services. The digital provisioning programs that weredeveloped prior to the new architectures or components did not includenor address issues related to the new architectures or components.

Typically, when technology evolved with new architectures or components,the digital provisioning programs required major reprogramming oroverhaul. Even if a digital provisioning program was overhauled toinclude new architectures or components, the overhauled digitalprovisioning program would be out-of-date just as soon as even newerarchitectures or components came into usage.

Another drawback of the digital provisioning programs was that thereprogramming of the programs could generate additional problems. Thedigital provisioning programs became more complex and convoluted witheach reprogramming or overhaul. Thus, reprogramming, and even running, adigital provisioning program could become increasingly more expensivewith each overhaul.

Yet another drawback of the digital provisioning programs was that theyoften inadequately addressed significant increases in workload withrespect to span design. Generally, the digital provisioning programsprocessed each span design in the same manner by processing one spandesign at a time. Some of the drawbacks associated with increasedworkload could have been addressed by increasing the number of employeesand/or the number of hours that employees were working. An obviousproblem with increased workload or increased personnel is that it hasthe potential to become financially prohibitive, a negative influence onemployee morale, etc.

In sum, there is a need for methods and systems of dynamic, costeffective, and flexible span design that have the ability to easilyaddress increasing workloads, new architectures or components, orchanged circumstances.

SUMMARY OF THE INVENTIONS

The methods and systems according to the inventions overcome thedrawbacks of the prior art. The inventions provide systems and methodsfor span design for the provisioning of digital services in thetelecommunications industry. The inventions may be implemented through acomputerized methodology to dynamically add, change or delete componentssuch as network elements, segments, or architectures used in spandesign. The inventions may include rules that govern the components, andthe relationships among them as well as other factors of thetelecommunications environment. The inventions provide span designmethods and systems that may be altered with minimal or no effort, butyet meet the continuously changing environment of the provisioning ofdigital services in the telecommunications industry.

Generally stated, the inventions receive an order for digital services,create a span design, send the span design to the field force, and mayprovide information to the appropriate entities.

An exemplary method of the inventions provides a span design in responseto receipt of an order for digital services. The order data is used toobtain an assignment of components for the digital services. The orderdata and the assignment of components are used to obtain equipment data.The order data, the assignment of components, and the equipment data areused to create the span design. An administrative review of the spandesign may be conducted such as a check that each of the components inthe span design conforms to one or more rules. If appropriate, the spandesign may be sent to the field force for implementation of the spandesign for the provision of the digital services.

Particularly, the span design may be based on a hierarchy of componentsincluding elements, segments, and architectures. The elements are thebasis of the hierarchy. Elements may be combined to form a segment.Segments may be combined to form an architecture. Other combinations ofthe components in each type in the hierarchy may be used. Further, eachcomponent conforms to one or more rules.

Another embodiment of the inventions provides another method forcreating a span design for digital services. In this exemplary method,templates are developed for use in creating span designs. A template maybe a representation of one or more components for the provision of thedigital services. The components comply with rules. The components in atemplate may include element(s), segment(s), architecture(s), or anycombination thereof. When an order for digital services is received, theorder data and other information may be used to select one or more ofthe templates as a span design for the order. The other information mayinclude an assignment of components and equipment data.

The inventions also include an exemplary system for span design inprovisioning digital services. The system includes a main module forreceipt of an order for the digital services. The main module providesthe order data to an assignment control system (ACS). The ACS makes anassignment of one or more components for the digital services andprovides the main module with the assignment data. The main moduleprovides the assignment data and may provide the order data to aninventory module (IM). The IM uses the assignment data and may use theorder data to determine equipment data, and provides the equipment datato the main module. The main module uses the order data, the assignmentdata, and the equipment data to create the span design for the digitalservices.

In the exemplary system, the main module may create the span designbased on templates. The templates may include one or more elementtemplates. Each of the element templates may represent an element. Thetemplates may include one or more segment templates. Each of the segmenttemplates may represent a segment, which may include one or moreelements. The templates may include one or more architecture templates.Each of the architecture templates may represent an architecture, whichmay include one or more segments.

In sum, the inventions allow for relatively quick, cost effective, andefficient span design to accommodate the increasing numbers of ordersfrom customers for digital services. Such quick, cost effective, andefficient span design is brought about by one or more of the features ofthe inventions such as the organization of telecommunications componentsinto a hierarchy, the use of templates based on the hierarchy, and theapplication of rules to each of the components in a span design.

These and other feature and advantages of the methods and systemsaccording to the inventions may be more clearly understood andappreciated from a review of the following detailed description of thepreferred embodiments and by reference to the appended drawings andclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary environment for theinventions.

FIG. 2 is a block diagram of an exemplary digital provisioningclient-server network.

FIG. 3 is a flow diagram of the actions taken by an exemplary digitalprovisioning client-server network.

FIG. 4 is a flow diagram of some actions taken by an exemplaryembodiment of the inventions.

FIG. 5 illustrates an example of the hierarchical organization ofelements, segments, and architectures as may be used with theinventions.

FIG. 6 is an exemplary template table.

FIG. 7 is a flow diagram of some actions taken by an exemplaryembodiment of the inventions.

FIG. 8 is an exemplary rules table.

DETAILED DESCRIPTION

The detailed description uses a number of acronyms that are generallywell known in the art. Definitions are typically provided with the firstinstance of each acronym, but for convenience, Table 1 below provides alist of some of the acronyms and abbreviations used herein along withthe terms they represent. TABLE 1 ACRONYM DEFINITION CFA CarrierFacility Assignment CKL Circuit Location C.O. Central Office DPRODigital Provisioning computer program DS-1 Digital Signal Level 1 DS-3Digital Signal Level 3 DSL Digital Subscriber Line FID FieldedIDentifier GUI Graphical User Interface HDSL High Bit Rate DigitalSubscriber Line LEIM ™ Loop Electronics Inventory Module LFACS LoopFacility Assignment Control System NPA Numbering Plan Area (a.k.a. AreaCode) PC Personal Computer PDA Personal Digital Assistant PSTN PublicSwitched Telephone Network RMA Request for Manual Assistance SOACService Order Analysis and Control SONET Synchronous Optical Network SUBSubsection Routing Code (a.k.a. Sub number) T-1 Trunk Carrier SignalLevel 1 TIRKS ™ Trunks Integrated Records Keeping System ZNEA Aspecialized Fielded Identifier (FID) on a service order indicating localfacility assignments are NOT required. The letters have no particularmeaning.An Exemplary Environment—FIG. 1

FIG. 1 illustrates an exemplary environment 10 for the inventions. Theexemplary environment 10 includes a Public Switched Telephone Network(PSTN) 12 with a network of interconnected central offices (C.O.s) 14a-n. A C.O. also may be referred to as an end office (E.O.), a serviceswitching point (SSP), or a terminating office (T.O.).

C.O.s 14 a-n may utilize connections 16 a-n to users 18 a-n. Aconnection may be any type of link, respectively, between a C.O. 14 a-nand a user 18 a-n that may be used for high data rate communications.For example, a connection may be, without limitation, a fixed line, adigital subscriber line (DSL), a T-1 line, a T-3 line, a cable, asatellite link (both high and low earth orbit), high speed fixed orspread spectrum wireless, hybrid wireless/fixed lines, VDSL/FTTC(Very-High-Data-Rate DSL/Fiber-to-the-Curb), power lines, etc. Further,the connections 16 a-n need not be all of the same type; nor do each ofthe connections 16 a-n have to be of a different type.

A user 18 a-n may be any person and/or entity that uses digitaltelecommunications service. For example, a user 18 a-n may be, amongother things, a person at his or her home, an internet service provider,a telemarketing company, an educational or medical institution, abusiness or service organization operating in an office or otherbuilding, or other entity.

Digital telecommunications service generally refers to high data ratecommunications such as DS-1 service, DS-3 service, T-1 service, or thelike. Digital telecommunications service also may be referred to asdigital service.

When a user 18 a-n subscribes to digital service, a check is made by theservice provider to determine whether there is an appropriate path bywhich to provide the service to the user. That portion of the pathbetween the user 18 a-n and the element of the PSTN 12 connecting theuser 18 a-n to the digital service is referred to as the span withrespect to that user 18 a-n.

A user's span may be the connection between the user 18 a-n and the PSTN12. For example, in FIG. 1, user 18 a is connected via connection 16 ato the PSTN 12, and in particular, to C.O. 14 a of the PSTN 12. In thisexample, C.O. 14 a is appropriately configured to provide the user 18 awith digital service. Thus, the span of user 18 a is the connection 16a.

In some cases, the C.O. serving a user may not include or have access tocomponents appropriate to providing the user with digital service. Inthat case, the user's span used in the provisioning of digital serviceto the subscriber may include the C.O. serving the user and itsconnection to another element of the PSTN. For example, in FIG. 1,assume C.O. 14 b does not include the appropriate components to provideuser 18 b with digital service. When user 18 b subscribes to digitalservice, the span used in the providing of digital service to user 18 bincludes connection 16 b between the user and C.O. 14 b, and theconnection 15 a that links C.O. 14 b to C.O. 14 a, which providesdigital service.

In some cases, the span may be limited to the path between two elementsof the PSTN. For example, assume digital service is to be provisioned toC.O. 14 b where a co-located Local Exchange carrier has a presence.Also, assume C.O. 14 c provides digital service. Thus, the span forprovisioning C.O. 14 b with digital service may include the connection15 b between C.O. 14 b and C.O. 14 n and the connection 15 c betweenC.O. 14 n and C.O. 14 c.

An Exemplary Digital Provisioning Network—FIG. 2

The inventions include methods and systems that may be used for creatingspan designs for providing digital services. A span design is a designof the features, components, elements, etc. that are part of the span ofthe telecommunications network used to deliver digital services to auser.

An exemplary system may be a network involving the interaction of one ormore servers and one or more clients within a “client-server” network.The “client-server” network may refer to a hardware configuration, to asoftware configuration, or to a combination thereof. Any device orprogram may be capable of acting as a client and/or a server dependingon the role the device or program plays based on the nature of theconnection between the device or program and other elements. In otherwords, rather than a specific type of device or program, the terms“client” and “server” refer to the role a device or program performsduring a specific connection or communication with another device,program, or element.

An exemplary system of the inventions, referred to as a DigitalProvisioning Network 20 (DPRO), is illustrated in the block diagram ofFIG. 2. DPRO may also be implemented as a computer program or otherwise.In this example, DPRO 20 is a client-server network including, but notlimited to, a main module 22, a database 24, a Loop Facility AssignmentControl System 26 (LFACS), a Loop Electronics Inventory Module 28(LEIM™), Service Order Analysis and Control 34 (SOAC), a Graphical UserInterface 30 (GUI), and an administrator 32.

In this example, the main module 22 of DPRO 20 is communicativelyconnected to database 24, LFACS 26, LEIM™ 28, SOAC 34 and GUI 30. Thedatabase 24 is also communicatively connected to GUI 30, which iscommunicatively connected to the administrator 32.

In the exemplary DPRO 20, the main module 22 acts as a server in theclient-server network, and may also be referred to as a DigitalProvisioning module (DPRO module). The main module 22 may be aclient-server network or the like.

Generally stated, the exemplary DPRO is designed to receive an order fordigital services, create a span design, send the span design to thefield force, and provide information to the appropriate entities.

Particularly, the main module 22 of the exemplary DPRO 20 receives anorder. Typically, the order is received from SOAC 34, but may bereceived from other sources such as a user 18 a-n, another client orelement in DPRO, or elsewhere.

In this exemplary embodiment, there are two types of orders: a serviceorder and a work order. A service order is a set of instructions thatmay specify the following: what type of digital service is to beprovided; for whom the service is to be provided; and where the serviceis to be provided. For example, a service order may specify that aparticular customer has requested DS-1 service for the customer's placeof business. A service order is generally created from a customer'srequest, but may be provided to DPRO by an administrator, a server,client, or other entity connected to DPRO. A service order may containuser information including, but not limited to, identification of thecustomer, a specific location, type of digital service desired, and whenthe service is needed. Additionally, a service order may include acustomer's billing information.

Alternatively, an order may be a work order. A work order is like aservice order, but typically a user does not initiate a work order.Instead, a work order may be initiated by an administrator to address aproblem or potential problem with an existing span design. For example,an administrator may issue a work order to re-route DS-1 service to aparticular user due to the physical relocation of a remote terminal.Analogous to a service order, a work order may specify user informationincluding, but not limited to, the identity of the user, a specificlocation, type of service desired, and when the service is needed.

As noted above, the main module 22 of the exemplary DPRO 20 illustratedin FIG. 2 is communicatively connected to other elements. One of theseelements is database 24, which may be utilized to store information.Among other things, database 24 may be a log, a record, a table, or astorage device. For example, database 24 may be a storage device thatrecords and stores information (also referred to as order data) from anorder received by DPRO 22. As another example, the main module 22 mayaccess the database 24 for various reasons as explained below.

The main module 22 of the exemplary DPRO 20 is also communicativelyconnected to the Loop Facility Assignment Control System 26 (LFACS).LFACS may contain inventory information regarding components that areavailable for use in providing digital services and that may beincorporated in a span design. The components may include cables, pairs,and terminals. A “pair” refers to the two wires that make up the user'sloop for telecommunications service between the user and the C.O.serving the user. A “cable” is a wire or a group of wires capable ofcarrying voice or data communications. A “terminal” is a connectionpoint for elements such as a pair or cable with regard to thetransmission of voice or data communications.

The inventory information of LFACS may identify each cable by cablename, and include information on each cable's length and gauge. Theinventory information may identify the pairs by pair numbers and theterminals by terminal addresses.

In the course of creating a span design, the main module 22 may provideLFACS 26 with order data from the order for digital services. Inresponse, LFACS 26 may provide the main module 22 with an assignmentincluding assignment data relating to the assigned components.

The main module 22 of the exemplary DPRO 20 may be communicativelyconnected to the Loop Electronics Inventory Module 28 (LEIM™). LEIM™ 28may store data on equipment that may be used as components in a spandesign. The data may be referred to as equipment data and may include:equipment name (including series or other identifier), equipmentfeatures, physical location of the equipment, relay rack informationrelating to the equipment, etc. For example, LEIM™ 28 may store data onconnections for digital signal cross connect panels for the equipment,as well as equipment data for, among other things, multiplexers,repeater shelves, line repeaters, etc.

LEIM™ 28 may store equipment data such as information on theavailability for use of any particular piece of equipment as a componentor part of a component in a span design. In the course of creating aspan design, the main module 22 may provide LEIM™ 28 with assignmentdata from LFACS 26. In response, LEIM™ 28 may provide the main module 22with equipment data specific to the given assignment data, that is, theassigned components for the provision of the digital services relatingto the span design. A component may be a network element, a networksegment, or a network architecture. The differences among these types ofcomponents and their relationship is explained below in connection withFIG. 3.

Additionally, the data associated with the network elements, networksegments, and network architectures (discussed further in relation toFIG. 5) may be stored within any of the clients within the client-servernetwork. For example, data regarding elements may be stored in LEIM™LFACS, and/or the database.

The main module of the exemplary DPRO 20 may be communicativelyconnected to a graphical user interface 30 (GUI) or other interface. GUI30 may be utilized for communications between DPRO 20 and anadministrator 32. The GUI 30 generally may be 25 accessed through anydevice capable of displaying and/or printing information. For example,GUI 30 may be accessed through, among other things, a monitor, aworkstation, an email account, a fax machine, a computer printer, apersonal digital assistant (PDA), or a television screen.

Advantageously, GUI 30 is typically a Windows-based interface andtherefore easy to understand and use for someone relatively familiarwith Windows-based environments. The administrator 32 may utilize theGUI 30 to communicate with the main module 22 including review of,modification of, acceptance and/or rejection of suggestions and/or spandesigns from the main module 22. Additionally, the administrator 32 mayutilize the GUI 30 to access and/or modify the database 24. Theadministrator 32 may be any person, entity, computer, automated programand/or the like responsible for operation of and monitoring the spandesign process. Even though only one administrator 32 is described inconnection with this exemplary embodiment, there may be more than oneadministrator.

Once the exemplary DPRO 20 completes a span design, it may be providedto the field forces. Field forces may refer to an administrator and/oremployee(s) responsible for the monitoring, operation, and/or physicalimplementation of span designs. Additionally, the exemplary DPRO 20 mayprovide information associated with a span design to other clientsand/or servers outside of the client-server network associated with theexemplary DPRO 20. For example, the exemplary DPRO 20 may provideinformation associated with a span design to a record system such as theTrunks Integrated Records Keeping System (TIRKS™).

Flow Diagrams of an Exemplary Embodiment—FIGS. 3-7

FIG. 3 is a high level overview 40 of an exemplary DPRO provisioningprocess illustrated through use of a flow diagram. The process beginswith the receipt of an order containing order data in action 42. Orderdata or other information associated with the data may be stored as wellas acted upon as described below.

A span design is created or at least attempted in action 44. Detailsregarding the creation or attempts at creation of the span design areprovided below with reference to FIGS. 3 and 4.

If a span design is created as determined in action 44, then in action46, the span design is checked for compliance with the rules of DPRO.Details regarding exemplary DPRO rules are provided below with referenceto FIG. 8.

The result of the compliance check is issued in a Request for ManualAssistance (RMA) in action 48. In the exemplary embodiment, an RMA is anotification provided to an administrator. As an example, an RMA maycontain a proposed span design for an administrator to accept, reject,or modify.

Further, in the exemplary embodiment, an RMA may be distinguished as oneof two types: a span design level RMA; or a non-span design level RMA. Aspan design level RMA is an RMA related to a span design, and mayinclude or reference a span design. For example, a span design level RMAmay include an RMA issued when the main module accesses a rules template(rules templates are described below in relation to FIG. 8).

A non-span design level RMA is an RMA that is unrelated to a spandesign. Non-span design level RMAs may include, among other things,service order RMAs, LEIM™ RMAs, and LFACS RMAs. Service order RMAs mayrefer to (ZNEA) errors (errors where the usage (presence or absence) ofthe ZNEA FID is ambiguous, etc. LEIM™ RMAs may refer to warnings that norelevant data exists in LEIM™, etc. LFACS RMAs may address incompleteassignments, problems accessing LFACS, missing order data in LFACS,location not matched in LFACS, LFACS being unavailable, etc.

Generally, span design level RMAs require some action such as correctiveaction by the administrator prior to proceeding with the provisioningprocess than non-span design level RMAs. Non-span design level RMAs maynot require any action by the administrator.

An RMA's type may determine the manner in which the administratoraddresses the RMA. Additionally, an RMA's type may require a differentlevel of importance and/or urgency from another type of RMA. Forexample, span design level RMAs may signal a greater level of urgencythan non-span design level RMAs. Advantageously, the categorization ofRMAs by type gives an administrator flexibility in addressing RMAs. Thisflexibility may allow for faster, more efficient span design.

Referring again to action 44 of determining whether a span design hasbeen created, if no span design is created, then the exemplary processissues an RMA in action 48. The RMA may include information on why thespan design was not created.

The RMA is reviewed in action 50, preferably by an administrator. Thereview may result in action with respect to the processing of the order.If so, then the process may re-start (with the action completed orotherwise) with the action of span design creation or at least attemptat creation in action 44. If the review of the RMA results in a findingthat no further action is necessary with respect to the span design,then the span design may be sent to the field force in action 54.

More particularly, the review of the RMA in action 50 may present theadministrator with a proposed span design. An administrator may acceptthe proposed span design, reject the proposed span design, or makemodifications to it.

If the administrator accepts the proposed span design, then as notedabove, in action 52 a determination is made that no further action isnecessary and in action 54 the proposed span design is sent to the fieldforce as the span design for the order.

If the administrator rejects the proposed span design, then typicallythe administrator provides information, modifies information, or takesother action. Based on the action, the exemplary DPRO process mayre-start so as to create another proposed span by returning to action 44of FIG. 3.

If the administrator makes modifications to the proposed span design, adetermination may be made as to whether or not the changes altered anycritical aspects of the proposed span design or otherwise affectedinformation related to the proposed span design. If the changes did notalter any of the critical aspects of the span design or relatedinformation, the changed proposed span design may be sent to the fieldforce as the span design for the order.

If, however, a critical aspect of the proposed span design or relatedinformation was altered by the administrator, the proposed span designmay be re-processed according to the actions described above to insurethat the changes made by the administrator to the proposed span designdid not affect another portion of the proposed span design.

An example of a situation when an administrator might make amodification to a span design is where the administrator is aware ofchanges that not yet be accounted for within an exemplary DPRO. Forexample, an administrator may know that a particular component selectedfor use within the span design has been replaced by another component(e.g.: an updated component). Thus, the administrator may modify theproposed span design to take into account the updated component.

Advantageously, the exemplary DPRO process is dynamic in adjusting tochanges in data that may affect the design for a span of a consumerordering digital services. For example, the exemplary method may createa span design and submit the span design for review. If the reviewresults in a change in data upon which the span design is based, thenthe exemplary method processes the changed data and creates a spandesign based on the changed data.

Another advantage of the exemplary DPRO is that an administrator mayhalt the process of creating a span design at any point, yet utilize thespan design created up to that point in the span design process.

Span Design Creation

There may be several stages with regard to span design. In the exemplaryDPRO, among the first stages of span design is a determination ofwhether the received order is new. A new order is an order includingorder data or other information that is deemed critical and that has notpreviously been received or processed by DPRO. Thus, a new order may bean order that is received for the first time prior to any processing byDPRO.

Further, a revised order (or not new) may be an order that has beenpreviously processed by DPRO, and as a result, includes order data orother information that is deemed critical and that may have been changedduring or after DPRO processing. As an example, refer to the overviewillustrated in FIG. 3 wherein an order may be processed through thedescribed actions, but have to “re-start” the process as a result of achange on the order or otherwise. After the administrative review 50,action 52 may be taken to update or change order data or otherinformation associated with the order. If the changes are made tocritical order data or other information, then the order is consideredto be “revised” during its reprocessing. Critical order data may includedata associated with circuit location (CKL), the subsection routing code(SUB), numbering plan area (NPA), network exchange (NXX), address,carrier facility assignment (CFA), absence or presence of the ZNEA FID,line code, or framing.

A reason for determining whether the order is new or not new is that anorder that is not new may, in some cases, more quickly process throughthe exemplary DPRO than a new order. The order that is deemed to be notnew may process faster typically because less processing is required.For example, an order that is not new may not require the exemplary DPROto access LFACS or LEIM as the data may already be stored in thedatabase.

The exemplary DPRO may utilize a differencer to determine whether or notthe order data is new. A differencer compares stored versions of theorder data (if any) with the version of the order data just received.

FIG. 4 illustrates details regarding the action of span design orattempt(s) at span design generally itemized as action 44 in FIG. 3. Inthe exemplary DPRO, as shown by action 60, a loop facility assignmentcontrol system (LFACS) assignment is obtained. An LFACS assignment alsomay be referred to as an assignment.

The example illustrated in FIG. 4 assumes an LFACS assignment isobtained. This may not always be the case, and there may be a failure toobtain an LFACS assignment. LFACS may determine that a criticalcomponent or components necessary to provide an assignment for the orderis missing or unavailable given the requirements of the order or orderdata. If no LFACS assignment is obtained, then no span design is createdas noted by action 68 in FIG. 4, and the DPRO process continues asdescribed with reference to action 48 (RMA issued) in FIG. 1. The RMAmay, for example, request the administrator to provide additionalinformation, or specify what action to take when LFACS assignmentscannot be obtained. The RMA may notify the administrator that the orderdata did not contain sufficient information, LFACS could not locate therequisite components, the assignment is incomplete, etc.

In the exemplary embodiment, an LFACS assignment includes componentsselected to be used in the span design for the provisioning of thedigital services relating to the order. The selection of the componentsfor the LFACS assignment is made with reference to the order data and toLFACS inventory information. The LFACS assignment may be made by LFACS,or by a user accessing the order data and inputting the LFACS inventoryinformation via keyboard.

In an alternate embodiment, LFACS may receive the order data at the sametime the main module receives the order data. LFACS may, at that time,make a determination as to whether LFACS may provide an LFACSassignment, or LFACS may have the LFACS assignment (or LFACS inventoryinformation or other information) prepared so as to be ready to respondimmediately after being accessed or queried.

As also illustrated in FIG. 4, in action 62 Loop Electronics InventoryModule (LEIM™) equipment data is obtained. LEIM™ equipment data also maybe referred to as equipment data.

It is assumed in the example illustrated in FIG. 4 that LEIM™ equipmentdata is obtained. This may not always be the case that there may be afailure to obtain LEIM™ equipment data. If no LEIM™ equipment data isobtained, then no span design is created as noted by action 68 in FIG.4, and the DPRO process continues as described with reference to action48 (RMA issued) in FIG. 3.

LEIM™ equipment data includes data on equipment selected to be used inthe span design for the provisioning of the digital services relating tothe order. The selection of the equipment for the LEIM™ equipment datais made with reference to the order data, LEIM™ inventory information,and may be made with reference to the LFACS assignment. The LEIM™equipment data may be specified by LEIM™, or by another element such asthe database of the exemplary DPRO using the order data, the LEIM™inventory information, the LFACS assignment, or other information.

In action 64, the LFACS assignment, the LEIM™ equipment data may beassociated with the order data relating to the order for which a spandesign is being provisioned. The LFACS assignment, the LEIM™ equipmentdata, and the order data are used to select one or more templates toconstitute the span design.

A template is a pattern of network element(s), segment(s), and/orarchitecture(s) that constitutes a span design or part of a span design.The exemplary DPRO uses template(s) to create a span design. A networkelement also may be referred to as an element, a network segment alsomay be referred to as a segment, and a network architecture also may bereferred to as an architecture.

FIG. 5 illustrates the evolution of an exemplary template that may beused as a span design when appropriate. As noted, a template is apattern of network element(s), segment(s), and/or architecture(s). Thetemplates of the exemplary DPRO have been created based on issue(s) thatmust be addressed by the span designs or portions of span designsregarding the delivery of digital services.

Referring to FIG. 5, assume customer A 8 has placed an order for digitalservices and a span design must be created for the span 82 betweencustomer A 80 and a central office (C.O.) 84. In this example, assumethe span design must address two issues: issue X 86; and issue Y 88.Network elements A 90, B 92, and C 94 are used to address issue X 86,and network elements D 96, E 98, F 100, and G 102 are used to addressissue Y 88 as illustrated in FIG. 4 by their inclusion in span 82.

In this example, both issue X 86 and issue Y 88 are relatively commonissues faced in span design. Accordingly, the network elements A 90, B92, and C 94 that address issue X 86 may be grouped together as networksegment A 104. A record of this grouping of these network elements intoa network segment A 104 that addresses issue X 86 is referred to hereinas segment template A 106. Whenever the exemplary DPRO receivesinformation that a span design must address an issue X, DPRO may usesegment template A 106 as part of the span design to address such issueX.

As noted, network elements D 96, E 98, F 100, and G 102 address issue Y88 that arises in the design for span 82 between the customer A 80 andC.O. 84. These network elements may be grouped together as networksegment B 108. A record of this grouping of network elements into anetwork segment B 108 that addresses issue Y 88 is referred to herein asa segment template B 110. Whenever the exemplary DPRO receivesinformation that a span design must address an issue Y, DPRO may usesegment template B 110 as part of the span design to address such issueY.

As shown in FIG. 5, a way to illustrate the span design for span 82 isto include segment A 104 connected to segment B 108 in span 82.

In this example, the presence of issue X 86 and issue Y 88 is arelatively common occurrence in span design. Accordingly, the segmentsthat address these issues may be grouped into an architecture A 112. Arecord of this grouping of network segments into network architecture A112 that addresses issue X 86 and issue Y 88 is referred to herein as anarchitecture template A 114. Whenever the exemplary DPRO receivesinformation that a span design must address an issue X and an issue Y,DPRO may use architecture template 114 as the span design or part of it.

As shown in FIG. 5, another way to illustrate the span design for span82 is to include architecture A 112 in span 82.

The exemplary DPRO gains several advantages by using templates based ona hierarchy of network elements, segments, and architectures forcreating a span design. For example, using the templates in span designsaves time. A template may be created for each issue or combination ofissues that repeatedly arise in span design. Whenever an issue orcombination of issues arises, the appropriate template may be used inthe span design without resort to time-consuming analysis to determinethe appropriate network element or combination of network elements to beused in the span design.

Another advantage of DPRO's templates is that they are based on thehierarchy of network elements, segments, and architectures explainedabove. This hierarchy allows for templates to be of different “sizes”.Templates may be of different “sizes” in that they may include one ormore elements, one or more segments, one or more architectures, orcombinations thereof. The different sizes of the templates allow forflexibility in the creation of a span design as well as time savings insuch design. Referring to the example illustrated in FIG. 5, the spandesign for span 82 may quickly be determined to be architecture A 112based on the dual issues of X and Y that must be addressed in thedesign. The need for determining which specific network elements arenecessary to address these issues is avoided because they are specifiedby architecture template A 114.

Another example of how the templates speed up design span creation isillustrated by the circumstances of a span that presents issue X, issueY, and issue Z. As noted above, a template of architecture A 112 may beused in the span design to address issues X and Y. Assume there is notemplate for issue Z (alone or in combination with issue X and/or issueY). The exemplary DPRO may process the order including specification ofarchitecture A 112 as part of the span design, and report the lack of atemplate for issue Z in an RMA. Thus, the administrator only has toaddress issue Z in the span design instead of having to address allthree issues.

Yet another example of how the templates speed up span design relates tochanges in elements that may be used in a span. An element may becomeobsolete, may be updated, or otherwise changed. A new element may becomeavailable. The use of templates easily accounts for such changes. Anadministrator may only have to change the template(s) including thechanged element. The administrator does not have to revamp all of DPRO.Thus, the exemplary DPRO may be readily updated when an element changeoccurs.

FIG. 6 illustrates an exemplary template table 120. The exemplary DPROmay use the template table 120 to determine which template(s) to use inconnection with a span design. The illustrated template table 120includes a column 122 for identification of the templates and a column124 related to the issues addressed by the respective templates. Eachentry in the table includes an identifier in column 122 and an issue orpurpose in column 124.

The exemplary template table 120 includes entries relating to elements.In the exemplary embodiment, there is no need for a template for anelement in a span design. An element is a singular object or device,which may be used in a span design for a specific purpose. Thus, theelement entries 126 a, 128 a, and 130 a in template table 120 each havea respective purpose (K purpose 126 b, L purpose 128 b, and M purpose130 b) identified in column 124 of the template table 120. Such entriesrelating to individual elements may be useful in some embodiments of theDPRO process.

The term “purpose” is used as a generic term to cover the many differentreasons elements may be used in a span design. For example, element A126 a may be used for a particular function(s) that is(are) referred toas K purpose 126 b. In the course of span design, if the particularfunction(s) that constitute(s) the K purpose are present, element A 126a may be selected for use in the span design.

The exemplary template table 120 also includes entries relating tosegments. Typically, a segment includes more than one element and asegment may be used in a span design to address a particular issue.Template table 120 includes the following entries relating to segments:segment A 132 a addressing X issue 132 b; segment B 134 a addressing Yissue 134 b; and segment C 136 a addressing Z issue 136 b.

The term “issue” is used as a generic term to cover the many differentreasons segments and architectures may be used in a span design. Forexample, segment A 132 a may be used for a particular function(s) thatis(are) referred to as X issue. In the course of span design, if theparticular function(s) that constitute(s) the X issue are present,segment A 132 a may be selected for use in the span design.

Further, the exemplary template table 120 includes entries relating toarchitectures. Typically, an architecture includes one or more elements,one or more segments, or one or more segments plus elements. Anarchitecture generally is used to address more than one issue and/orpurpose. Template table 120 includes the following entries relating toarchitectures: architecture A 138 a addressing X issue plus Y issue 138b; architecture B 140 a addressing X issue plus Z issue 140 b; andarchitecture C 142 a addressing Y issue plus Z issue 142 b.

Exemplary template table 120 is included herein primarily for purposesof explanation of the principals of the inventions. The inventions mayuse or include other mechanisms for the storing of information relatedto templates, elements, segments, and architectures, and associatedinformation.

As noted above with reference to FIG. 4, action 64, a span design iscreated for an order by using the order data, the LFACS assignment, andthe LEIM equipment data. The exemplary DPRO uses one or more templatesto create the span design as explained with reference to the flowdiagram of FIG. 7.

The creation of a span design may be viewed as a “top-down” approachbased on the hierarchy explained above of architectures typically beingmade up of segments, segments and elements, and segments being made upof elements. The exemplary DPRO first checks whether an architecturetemplate(s) may be used in the span design, then checks whether asegment template(s) may be used, and finally checks whether anelement(s) may be used. Advantageously, this top-down approach based onthe hierarchy of architecture-segment-element speeds span design. Forexample, a span design may be created that is based only on anarchitecture template. Once the exemplary DPRO has selected thearchitecture template, the span design may be considered complete.

FIG. 7 illustrates the top-down approach to span design as starting inaction 162 with a check of the template table (described above withreference to FIG. 6) for an architecture template to be used in the spandesign. To aid in the explanation, assume the span design must take intoaccount:X issue+Y issue+Z issue+K purpose.The exemplary DPRO checks the template table 120 for an architecturetemplate that may relate to these issues and purpose.

If no architecture template is found in the check 164, then the spandesign process moves on to checking for segment templates in action 174as explained below.

Referring to the example, the exemplary DPRO finds architecture Atemplate 138 a may be used to address:X issue+Y issueIn action 168 the exemplary DPRO may check whether the span design iscomplete. If complete, then in action 170 an RMA may be sent. If thespan design is incomplete as determined in action 168, then in action172 a check may be conducted to see whether the template table needs tobe checked again for an architecture template. If so, the processreturns to action 162 and checks for the architecture template.

Still referring to FIG. 7, if no architecture template is found (action164), or if the span design is incomplete (action 168) and there is noneed for an architecture template check (action 172), then in action 174a check is conducted for a segment template.

If no segment template is found, then the span design process moves onto checking for elements in action 186 as explained below.

Referring to the example, the exemplary DPRO finds that segment Ctemplate 136 a may be used to address: Z issue. In action 180 theexemplary DPRO may check whether the span design is complete. Ifcomplete, then in action 182 an RMA may be sent. If the span design isincomplete as determined in action 180, then in action 184 a check maybe conducted to see whether the template table needs to be checked againfor a segment template. If so, the process returns to action 174 andchecks for the segment template.

Still with reference to FIG. 7, if no segment template is found (action176), or if the span design is incomplete (action 180) and there is noneed for a segment template check (action 184), then in action 186 acheck is conducted for an element template.

If no element template is found, then an RMA is sent in action 190.

Referring to the example, the exemplary DPRO finds element A 126 a maybe used to address: K purpose. In action 192 the exemplary DPRO maycheck whether the span design is complete. If complete, then in action196 an RMA may be sent. If the span design is incomplete as determinedin action 192, then in action 194 a check may be conducted to seewhether the template table needs to be checked again for an elementtemplate. If so, the process returns to action 186 and checks for anelement template. If there is no need for an element template check(action 194), then an RMA is sent in action 196.

Using the above-described top-down approach, the span design created toaddress the example of:X issue+Y issue+Z issue+K purposehas created the following span design of:Architecture A+Segment C+Element A

The top-down process of span design described above is one way in whichthe hierarchy of architectures-segments-elements may be taken advantageof. Other processes may be used. For example, a “bottom-up” process maybe used where elements are first selected for an order. After selection,the elements may be determined to constitute segments, and the segmentsor segment(s) plus element(s) may be determined to constitutearchitectures. Other processes using the hierarchy ofelements-segments-architectures will occur to those skilled in the art.

Rules—FIG. 8

Among the features of the exemplary DPRO is the feature of uniformitywith respect to types of elements, segments, and architectures. Theuniformity generally allows for problem-free span design. Typically,there are no surprises or unexpected problems in the span design createdby the exemplary DPRO because the elements, segments, and architecturesare uniform with respect to each of their types. Since each element A islike every other element A, use of a particular element A does notgenerally result in problems because the particular element A is a“standard” element A with no quirks or special requirements.

The uniformity of types of elements, segments, and architectures in theexemplary DPRO is brought about by the application of a “rule” or“rules”. Each respective type of element, segment, or architecturesatisfies the rule or rules applied to it. A rule may cover a feature orspecification relating to an element, segment, or architecture. A rulemay relate to the relationships between elements, elements and segments,elements and architectures, segments and segments, segments andarchitectures, and architectures and architectures. A rule may relate tothe order of developing templates for use in elements, segments, orarchitectures. A rule may relate to conditions that may exist prior toprocessing of the span design without being specifically related to anyarchitecture, segment or element. A rule may relate to the level ofservice (DS1, T1, DS3, etc.) being processed. A rule may also relate tothe display of the completed design in the output or to whom the outputis sent.

FIG. 8 illustrates an exemplary Rules Table 200. The Rules Table 200includes a column 202 for a particular item such as an element, asegment, or an architecture. The Rules Table 200 also includes a column204 for the rule(s) applied to the corresponding item. The exemplaryRules Table 200 includes three entries with each entry including an itemand a rule(s). The first entry, Architecture A 206, is governed by theset of rules 208: Rules 3, 5, 2, 7, 35, 20 through n. The second entry,Segment B 210, is governed by the set of rules 212: Rules 31, 33, 4, 9,10, 27 through n2. The third entry, Element C 214, is governed by theset of rules 216: Rules 44, 8, 57, 1, 6, 15, 28 through n3.

In the exemplary DPRO, the conformity of any particular element,segment, or architecture may be checked against its respective rule(s).To promote the consistency of span design in the exemplary DPRO, theconformity of any particular element, segment, or architecture may bechecked during span design. Such a check may be carried out when anelement, segment, or architecture is selected for the span design.Alternatively, or in addition, a check may be carried out when the spandesign is considered complete.

Based on the elements-segments-architectures hierarchy, the exemplaryDPRO carries out a “bottom-up” check of the conformity of theelement(s), segment(s), and/or architecture(s) in a span design. Thebottom-up conformity check is viewed as advantageous because it is oftenmore efficient than other types of conformity checks. For example, thebottom-up conformity check carries out its check with respect to all ofthe element(s) present in a span design. Thus, when the bottom-upconformity check reaches the segment(s) and/or architecture(s) in thespan design, the conformity check does not have to re-check the elementswithin the segment(s) and/or architecture(s).

If a conformity check with respect to any component in a span designresults in a finding that the component does not conform to itscorresponding rules, then an RMA may be issued. Action may be taken tobring the component into compliance or to substitute a differentcomponent or combination of components.

Conclusion

In sum, the exemplary DPRO provides advantageous methods and systems ofspan design for digital services. The exemplary DPRO facilitatesrelatively quick, cost effective, and efficient span design toaccommodate the increasing numbers of orders from customers for digitalservices. In addition, the exemplary DPRO has flexibility to addressevolving developments in technology, increasing workloads, and changedcircumstances.

From the foregoing description of the exemplary embodiments of theinventions and operation thereof, other embodiments will suggestthemselves to those skilled in the art. Therefore, the scope of theinventions is to be limited only by the claims below and equivalentsthereof.

1. A method for provisioning a span for digital services, comprising:receiving an order for the digital services; using order data to obtainan assignment of components for the digital services; using the orderdata and the assignment of components to obtain equipment data; andusing the order data, the assignment of components, and the equipmentdata to create a span design for the provision of digital services. 2.The method of claim 1, further comprising conducting an administrativereview of the span design.
 3. The method of claim 1, wherein the spandesign is created based on a hierarchy of the components.
 4. The methodof claim 3, wherein the hierarchy of the components comprises: elements,segments, and architectures.
 5. The method of claim 3, wherein thehierarchy of the components comprises: elements, segments with eachsegment including one or more of the elements, and/or architectures witheach architecture including one or more segments.
 6. The method of claim1, wherein each component conforms to one or more rules.
 7. The methodof claim 2, wherein conducting the administrative review of the spandesign comprises checking whether each component conforms to one or morerules.
 8. A method for creating a span design for digital services,comprising: developing templates for use in creating span designs;receiving an order for digital services; and using order data to selectone or more of the templates as a span design for the order.
 9. Themethod of claim 8, wherein a template comprises a representation of oneor more components for provision of the digital services.
 10. The methodof claim 8, wherein a template comprises a representation of one or moreelements, one or more segments, and/or one or more architectures. 11.The method of claim 8, wherein using the order data to select the one ormore of the templates as the span design for the order comprises: usingthe order data to select one or more architecture templates, one or moresegment templates, and/or one or more element templates as the spandesign for the order.
 12. The method of claim 8, wherein using the orderdata to select the one or more templates as the span design for theorder comprises: using the order data and an assignment of components toselect the one or more templates as the span design for the order. 13.The method of claim 12, wherein using the order data and the assignmentof components to select the one or more templates as the span design forthe order comprises: using the order data, the assignment of components,and equipment data to select the one or more templates as the spandesign for the order.
 14. The method of claim 9, wherein each componentconforms to one or more rules.
 15. A system for provision of a spandesign for digital services, comprising: a main module for receipt of anorder for the digital services; the main module being operative toprovide order data from the order to an assignment control system (ACS);the ACS being operative to make an assignment of one or more componentsfor the digital services, and to provide the main module with assignmentdata relating to the assignment; the main module being operative toprovide the assignment data to an inventory module (IM); the IM beingoperative to use the assignment data to determine equipment data, and toprovide the equipment data to the main module; and the main module beingoperative to use the order data, the assignment data, and the equipmentdata to create the span design for the digital services.
 16. The systemof claim 15, wherein the main module is operative to create the spandesign based on templates.
 17. The system of claim 16, wherein thetemplates comprise: one or more element templates; one or more segmenttemplates; or one or more architecture templates.
 18. The system ofclaim 16, wherein a template comprises a representation of the one ormore components for the digital services.
 19. The system of claim 15,wherein components used for implementation of the digital services arehierarchically organized based on elements, segments, and/orarchitectures.
 20. The system of claim 19, wherein each of thecomponents comply with one or more rules.